 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| COREMP7 Product Summary * * * * * * * Personal Audio (MP3, WMA, and AAC Players) Personal Digital Assistants Wireless Handset Pagers Digital Still Camera Inkjet/Bubble-Jet Printer Monitors Verification and Compliance * * Compliant with ARMv4T ISA Compatible with ARM7TDMI-S Core Version * This Datasheet Defines the Functionality for COREMP7 v1.0. Contents Introduction ............................................................... 1 Device Utilization ....................................................... 2 General Description ................................................... 3 Programmer's Model ................................................. 7 AHB Wrapper ........................................................... 12 COREMP7 Variants ..................................................... 13 Delivery and Deployment ........................................ 14 Bus Functional Model .............................................. 14 AC Parameters .......................................................... 19 Debug ....................................................................... 23 Ordering Information .............................................. 28 List of Changes ......................................................... 28 Datasheet Categories ............................................... 29 Key Features * * * * * * * * * * * * FPGA Optimized ARM7TM Family Processor Compatible with ARM7TDMI-STM 32/16-Bit RISC Architecture (ARMv4T) 32-Bit ARM(R) Instruction Set 16-Bit Thumb(R) Instruction Set 32-Bit Unified Bus Interface 3-Stage Pipeline 32-Bit ALU 32-Bit Memory Addressing Range Static Operation EmbeddedICE-RTTM Real-Time Debug Unit JTAG Interface Unit Benefits * * * * Fully Implemented in FPGA Fabric All Microprocessor I/Os Available to User Unified Bus Interface Simplifies SoC Design ARM and Thumb Instruction Sets Can Be Mixed Introduction The COREMP7 soft IP core is an ARM7 family processor optimized for use in Actel ARM-ready FPGAs and is compatible with the ARM7TDMI-S. Users should refer to the ARM7TDM-S Technical Reference Manual (DDI0234A7TMIS-R4.pdf), published by the ARM Corporation, for detailed information on the ARM7. The ARM7 TRM is available for download from the ARM website at www.arm.com. COREMP7 is supplied with an Advanced Microcontroller Bus Architecture (AMBA) Advanced High-Performance Bus (AHB) compliant wrapper for inclusion in an AMBA-based processor system such as the one generated by the Actel CoreConsole IP Deployment Platform (IDP). ARM Supported Families * * ProASIC(R)3 (M7A3P) Fusion (M7AFS) Synthesis and Simulation Support * * * Directly Supported within the Actel Libero(R) Integrated Design Environment (IDE) Synthesis: Synplify(R) and Design Compiler(R) Simulation: Vital-Compliant VHDL Simulators and OVI-Compliant Verilog Simulators July 2007 (c) 2006 Actel Corporation v 2 .6 1 COREMP7 ARM7 Family Processor COREMP7 is a general purpose, 32-bit, ARM7 family microprocessor that offers high performance and low power consumption. The ARM architecture is based on Reduced Instruction Set Computer (RISC) principles. The simplicity of RISC results in a high instruction throughput and fast real-time interrupt response from a small and cost-effective processor core. Pipeline techniques are employed so that all parts of the processing and memory systems can operate continuously. Typically, while one instruction is being executed, its successor is being decoded, and a third instruction is being fetched from memory. The COREMP7 processor also implements the Thumb instruction set, which makes it ideally suited to high-volume applications with memory restrictions, or applications where code density is an issue. The 16-bit Thumb instruction set approaches twice the density of standard ARM code while retaining most of the ARM performance advantage over a traditional 16-bit processor using 16-bit registers. This is possible because Thumb code operates on the same 32-bit register set as ARM code. Thumb code is able to reduce up to 65% of the code size compared to 32-bit ARM Table 1 * Device Variant M7A3P1000 Core Only Core Plus Debug M7AFS600 Core Only Core Plus Debug 28.08 20.57 28.12 21.7 COREMP7 Utilization and Performance Performance (MHz) instructions, and offers 160% of the performance of an equivalent ARM processor connected to a 16-bit memory system. Device Utilization COREMP7 is available with and without debug for use in each ARM-enabled device. These variants (Core only or Core plus debug) are available in CoreConsole and are easily selected from the core configuration menus. The utilization and performance of the variants for each device are shown in Table 1. Core Only This variant of the COREMP7 is optimized for maximum speed and minimum size and does not include debug. Core Plus Debug This variant of the COREMP7 is optimized for minimum size and includes debug. Tiles RAM Block Utilization (%) 6,083 7,931 4 4 24.8% 32.3% 6,083 7,931 4 4 44.0% 57.4% 2 v2.6 COREMP7 General Description The COREMP7 processor architecture, core, and functional diagrams are illustrated in the following figures: * * * The COREMP7 block diagram is shown in Figure 1. The COREMP7 core is shown in Figure 2 on page 4. The COREMP7 functional diagram is shown in Figure 3 on page 5. EmbeddedICE-RT Macrocell LOCK WRITE SIZE[1:0] PROT[1:0] TRANS[1:0] ADDR[31:0] Databus WDATA[31:0] RDATA[31:0] Scanchain 1 Scanchain 2 DBGRNG(0) DBGRNG(1) DBGEXT(0) DBGEXT(1) CPU Coprocessor Interface Signals EmbeddedICE-RT TAP Controller DBGTCKEN DBGTMS DBGnTRST DBGTDI DBGTDO Figure 1 * COREMP7 Top-Level Block Diagram v2.6 3 COREMP7 ADDR[31:0] Address Register PC Bus Address Incrementer Incrementer Bus Register Bank ALU Bus Multiplier A Bus Instruction Decoder and Control Logic B Bus Shifter ALU CLK CLKEN CFGBIGEND nIRQ nFIQ nRESET ABORT LOCK WRITE SIZE[1:0] PROT[1:0] TRANS[1:0] DBG Outputs DBG Input CP Control CP Handshake Write Data Register Instruction Pipeline Read Data Register Thumb Instruction Decoder WDATA[31:0] RDATA[31:0] Figure 2 * COREMP7 CPU Block Diagram 4 v2.6 COREMP7 DBGTCKEN CLK Clock CLKEN nIRQ Interrupts nFIQ nRESET CFGBIGEND DBGTMS DBGTDI DBGnTRST DBGTDO DBGnTDOEN ADDR[31:0] WDATA[31:0] RDATA[31:0] DMORE Arbitration LOCK DBGINSTRVALID DBGRQ DBGBREAK DBGACK DBGnEXEC DBGEXT[1] Debug DBGEXT[0] DBGEN DBGRNG[1] DBGRNG[0] DBGCOMMRX DBGCOMMTX CPnMREQ CPSEQ CPTBIT CPnl CPA CPB Coprocessor Interface CPnTRANS CPnOPC Memory Management Interface CoreARM7 ABORT WRITE SIZE[1:0] PROT[1:0] TRANS[1:0] Memory Interface Synchronized EmbeddedICE-RT Scan Debug Access Port Bus Control Figure 3 * COREMP7 Functional Diagram The signals of the COREMP7 are listed in Table 2. Table 2 * Name ABORT CFGBIGEND CLK CLKEN CPA CPB DBGBREAK DBGEN DBGEXT[1:0] Signal Descriptions Type Input Input Input Input Input Input Input Input Input Memory abort or bus error Big/Little Endian configuration Clock Clock enable Coprocessor absent Coprocessor busy EICE breakpoint/watchband indicator Debug enable EICE external input 0 Description Note: The COREMP7 is available with either the native ARM7 bus interface or with an AHB wrapper. The use of the AHB wrapper changes or transforms some of the signals in Table 2. This is discussed in detail later in this document. v2.6 5 COREMP7 Table 2 * Name DBGnTRST DBGRQ DBGTCKEN DBGTDI DBGTMS nFIQ nIRQ nRESET RDATA[31:0] ADDR[31:0] CPnI CPnMREQ CPnOPC CPnTRANS CPSEQ CPTBIT DBGACK Signal Descriptions (Continued) Type Input Input Input Input Input Input Input Input Input Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Output Test reset Debug request Test clock enable EICE data in EICE mode select Interrupt request Fast interrupt request Reset Read data bus Address bus Coprocessor instruction (asserted low) Memory request (asserted low) Opcode fetch (asserted low) Memory translate (asserted low) Sequential address Processor in Thumb mode Debug acknowledge EICE communication channel receive EICE communication channel transmit Executed (asserted low) TDO enable (asserted low) EICE rangeout EICE data out ETM Instruction valid indicator Set when next data memory access is followed by a sequential data memory access Locked transaction operation Indicates code, data, or privilege level Memory access width Next transaction type (i, n, s) Write data bus Indicates write access Description DBGCOMMRX DBGCOMMTX DBGnEXEC DBGnTDOEN DBGRNG[1:0] DBGTDO DBGINSTRVALID DMORE LOCK PROT[1:0] SIZE[1:0] TRANS WDATA[31:0] WRITE Note: The COREMP7 is available with either the native ARM7 bus interface or with an AHB wrapper. The use of the AHB wrapper changes or transforms some of the signals in Table 2. This is discussed in detail later in this document. 6 v2.6 COREMP7 Programmer's Model This section summarizes the programmer's model of the COREMP7. Supporting detail is available in the ARM ARM7TDMI-S Technical Reference Manual (available for download at www.arm.com) and the ARM Architecture Reference Manual, which can be purchased at www.amazon.com. The COREMP7 processor implements the ARMv4T architecture and includes both the 32-bit ARM instruction set and the 16-bit Thumb instruction set. You must align these as follows: * * * Word quantities must be aligned to four-byte boundaries. Halfword quantities must be aligned to two-byte boundaries. Byte quantities can be placed on any byte boundary. Operating Modes The COREMP7 processor has seven operating modes: * User mode is the usual ARM program execution state, and is used for executing most application programs. Fast interrupt (FIQ) mode supports a data transfer or channel process. Interrupt (IRQ) mode is used for general-purpose interrupt handling. Supervisor mode is a protected mode for the operating system. Abort mode is entered after a data or instruction prefetch abort. System mode is a privileged user mode for the operating system. Undefined mode is entered when an undefined instruction is executed. Processor Operating States The COREMP7 processor has two operating states: ARM state: 32-bit, word-aligned ARM instructions are executed in this state. Thumb state: 16-bit, halfword-aligned Thumb instructions are executed in this state. In Thumb state, the Program Counter (PC) uses bit 1 to select between alternate halfwords. Note: Transition between ARM and Thumb states does not affect the processor mode or the register contents. * * * * * * Switching State You can switch the operating state of the COREMP7 between ARM state and Thumb state using the BX instruction. This is described fully in the ARM Architecture Reference Manual. All exception handling is performed in ARM state. If an exception occurs in Thumb state, the processor reverts to ARM state. The transition back to Thumb state occurs automatically on return. Modes other than User mode are collectively known as privileged modes. Privileged modes are used to service interrupts or exceptions, or to access protected resources. Registers The COREMP7 processor has a total of 37 registers: * * 31 general-purpose 32-bit registers 6 status registers Memory Formats The COREMP7 processor views memory as a linear collection of bytes, numbered in ascending order from zero: * * * Bytes 0 to 3 hold the first stored word. Bytes 4 to 7 hold the second stored word. Bytes 8 to 11 hold the third stored word. These registers are not all accessible at the same time. The processor state and operating mode determine which registers are available to the programmer. The ARM State Register Set In ARM state, 16 general registers and one or two status registers are accessible at any one time. In privileged modes, mode-specific banked registers become available. Figure 4 on page 8 shows which registers are available in each mode. The ARM state register set contains 16 directly accessible registers, r0 to r15. An additional register, the Current Program Status Register (CPSR), contains condition code flags, and the current mode bits. Registers r0 to r13 are general-purpose registers used to hold either data or address values. Registers r14 and r15 have special functions as the Link Register and Program Counter. Although both Little Endian and Big Endian memory formats are supported, it is recommended that you use Little Endian format. Data Types The COREMP7 processor supports the following data types: * * * Word (32-bit) Halfword (16-bit) Byte (8-bit) v2.6 7 COREMP7 Link Register Register 14 is used as the subroutine Link Register (LR). Register 14 (r14) receives a copy of r15 when a Branch with Link (BL) instruction is executed. At all other times, you can treat r14 as a generalpurpose register. The corresponding banked registers--r14_svc, r14_irq, r14_fiq, r14_abt, and r14_und--are similarly used to hold the return values of r15 when interrupts and exceptions arise, or when BL instructions are executed within interrupt or exception routines. Program Counter Register 15 holds the Program Counter (PC). In ARM state, bits [1:0] of r15 are zero. Bits [31:2] contain the PC. In Thumb state, bit [0] is zero. Bits [31:1] contain the PC. In privileged modes, another register, the Saved Program Status Register (SPSR), is accessible. This contains the condition code flags, and the mode bits saved as a result of the exception that caused entry to the current mode. Figure 4 shows the ARM state registers. ARM State General Registers and Program Counter System and User r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 (PC) r0 r1 r2 r3 r4 r5 r6 r7 r8_fiq r9_fiq r10_fiq r11_fiq r12_fiq r13_fiq r14_fiq r15 (PC) FIQ Supervisor r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_svc r14_svc r15 (PC) Abort r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_abt r14_abt r15 (PC) r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_irq r14_irq r15 (PC) IRQ Undefined r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13_und r14_und r15 (PC) ARM State Program Status Registers CPSR CPSR SPSR_fiq CPSR SPSR_svc CPSR SPSR_abt CPSR SPSR_irq CPSR SPSR_und = banked register Figure 4 * COREMP7 Register Organization in the ARM State 8 v2.6 COREMP7 The Thumb State Register Set The Thumb state register set is a subset of the ARM state set. The programmer has direct access to the following: * * * * * Eight general registers, r0-r7 The PC A Stack Pointer (SP) A Link Register (LR) The CPSR There are banked SPs, LRs, and SPSRs for each privileged mode. The Thumb state register set is shown in Figure 5. Thumb State General Registers and Program Counter System and User r0 r1 r2 r3 r4 r5 r6 r7 SP LR PC FIQ r0 r1 r2 r3 r4 r5 r6 r7 SP_fiq LR_fiq PC Supervisor r0 r1 r2 r3 r4 r5 r6 r7 SP_svc LR_svc PC Abort r0 r1 r2 r3 r4 r5 r6 r7 SP_abt LR_abt PC IRQ r0 r1 r2 r3 r4 r5 r6 r7 SP_irq LR_irq PC Undefined r0 r1 r2 r3 r4 r5 r6 r7 SP_und LR_und PC Thumb State Program Status Registers CPSR CPSR SPSR_fiq CPSR SPSR_svc CPSR SPSR_abt CPSR SPSR_irq CPSR SPSR_und = banked register Figure 5 * COREMP7 Thumb State Registers v2.6 9 COREMP7 The Relationship Between ARM State and Thumb State Registers The Thumb state registers relate to the ARM state registers in the following way: * * * * * Thumb state r0-r7 and ARM state r0-r7 are identical. Thumb state CPSR and SPSR, and ARM state CPSR and SPSR are identical. Thumb state SP maps onto ARM state r13. Thumb state LR maps onto ARM state r14. The Thumb state PC maps onto the ARM state PC (r15). These relationships are shown in Figure 6. Thumb State r0 r1 r2 r3 r4 r5 r6 r7 Stack Pointer (PC) Link Register (LR) Program Counter (PC) Current Program Status Register (CPSR) Saved Program Status Register (SPSR) ARM State r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 Stack Pointer (r13) Link Register (r14) Program Counter (r15) Current Program Status Register (CPSR) Saved Program Status Register (SPSR) Figure 6 * Mapping of Thumb State Registers to ARM State Registers Note: Registers r0-r7 are known as the low registers. Registers r8-r15 are known as the high registers. 10 v2.6 COREMP7 The Program Status Registers The COREMP7 core contains a CPSR and five SPSRs for exception handlers to use. The program status registers the following: * * * Hold the condition code flags Control the enabling and disabling of interrupts Set the processor operating mode The arrangement of bits is shown in Figure 7. Condition Code Flags Reserved Control Bits 31 30 29 28 27 26 25 24 23 N Z C V Overflow Carry or Borrow or Extend Zero Negative or Less Than Figure 7 * Program Status Register Format 8 7 I 6 F 5 4 3 2 1 0 T M4 M3 M2 M1 M0 Mode Bits State Bit FIQ Disable IRQ Disable The Condition Code Flags The N, Z, C, and V bits are the condition code flags. You can set these bits by arithmetic and logical operations. The flags can also be set by MSR and LDM instructions. The COREMP7 processor tests these flags to determine whether to execute an instruction. All instructions can be executed conditionally in ARM state. In Thumb state, only the Branch instruction can be executed conditionally. For more information about conditional execution, see the ARM Architecture Reference Manual. v2.6 11 COREMP7 AHB Wrapper The AHB wrapper interfaces between the COREMP7 native ARM7 interface and the AHB bus. The module translates access from the core to AHB accesses when the core is the current master. The external interface signals from the wrapper are described in Table 3. Table 3 * AHB Wrapper External Interface Direction Input Input Input Input Input Description Bus clock. This clock times all bus transfers. All signal timings are related to the rising edge of HCLK. Reset. The bus reset signal is active LOW and is used to reset the system and the bus. This is the only active LOW AHB signal. Transfer done. When HIGH the HREADY signal indicates that a transfer has finished on the bus. This signal can be driven LOW to extend a transfer. Transfer response. Indicates an OKAY, ERROR, RETRY, or SPLIT response. Bus grant. Indicates that the COREMP7 is currently the highest priority master. Ownership of the address/control signals changes at the end of a transfer when HREADY is HIGH, so a master gains access to the bus when both HREADY and HGRANT are HIGH. This is the 32-bit system address bus. Transfer type. Indicates the type of the current transfer. Transfer direction. When HIGH this signal indicates a write transfer and when LOW a read transfer. Transfer size. Indicates the size of the transfer, which can be byte (8-bit), halfword (16bit), or word (32-bit). Burst type. Indicates if the transfer forms part of a burst. The COREMP7 performs incrementing bursts of type INCR. Protection control. These signals indicate if the transfer is an opcode fetch or data access, and if the transfer is a Supervisor mode access or User mode access. 32-bit data from the MASTER. 32-bit data written back to the MASTER. Signal External Master I/F HCLK HRESETn HREADY HRESP[1:0] HGRANT HADDR[31:0] HTRANS[1:0] HWRITE HSIZE[2:0] HBURST[2:0] HPROT[3:0] HWDATA[31:0] HRDATA[31:0] Output Output Output Output Output Output Output Input 12 v2.6 COREMP7 COREMP7 Variants There are two implementations of COREMP7 (Core Only and Core Plus Debug). The utilization and performance of the variants are shown in Table 1 on page 2. Debug Interface Debug JTAG Signals ARM7TDMI-S Core Debug TAP Controller EmbeddedICE-RT (Debug) Bus Control Signals Address Data ARM7 CPU Coprocessor Signals Figure 8 * ARM7 TDMI-S Core Core Plus Debug The Core Plus Debug variant is configured with all features of the ARM7TDMI-S. The variant incorporates the full debug functionality of the ARM7TDMI-S and is fully compliant with RealView RVDS, RVDK, and other ARM software debug tools. No Coprocessor Interface The coprocessor interface is a rarely used feature in ARM7 family microprocessors and has been removed from COREMP7 to minimize area. Little Endian Only Most microprocessor-based systems use Little Endian byte ordering. The option of selecting Big Endian has been removed from COREMP7 to minimize area. Core Only The Core Only variant has the same features as the Core Plus Debug variant except that it does not include the ICE-RT debug block or the TAP controller, which reduces the size of the core. This means that the standard debug tools cannot be used with this variant of COREMP7. On-Chip RAM Consumed by Register Block To minimize the area, the COREMP7 variants map the processor register block into on-chip RAM. RAM blocks used to implement COREMP7 registers are no longer available for use in user designs. No Debug This is the most obvious characteristic of the Core Only variant. To reduce area, the Debug EmbeddedICE-RT macrocell, the EmbeddedICE-RT TAP controller, and the scan logic have been optimized out. This means that standard software debug tools cannot be used when this variant of the COREMP7 is instantiated. Users can employ the Core Plus Debug variant for development, and when the application has been fully tested and debugged, the Core Only variant can be instantiated to reduce area in the final shipping product. v2.6 13 COREMP7 Delivery and Deployment The COREMP7 is delivered in CoreConsole, and can be instantiated in design projects created in Libero IDE. The files included with COREMP7 consist of the Bus Functional Model (BFM) files and test wrapper, AHB wrapper, and the A7S secured CDB file. The A7S secured CDB file is instantiated on the user device at programming. This deployment flow is implemented to ensure that the design is kept completely secure at all times, and allows COREMP7 to be easily used with the standard design flow through the Libero IDE tool suite. and the system memory map presented to the ARM7 by the rest of the hardware. This document specifies the following aspects of the ARM7 BFM: * * * * * * Functionality BFM usage flow BFM script language Platforms Supported simulation tools Example BFM use case Bus Functional Model During the development of an FPGA-based SoC, a number of stages of testing may be undertaken. This can involve some, or all, of the following approaches: * * Hardware simulation, using Verilog or VHDL Software simulation, using a host-based instruction set simulator (ISS) of the SoC's processor Hardware and software co-verification, using a fully functional model of the processor in Verilog, VHDL, or SWIFT form, or using a tool such as Seamless BFM Usage Flow As the BFM is part of an overall system test strategy, it is helpful to look at the context in which it is used. Figure 9 on page 15 shows the various components within an example system-level testbench that can be generated by CoreConsole. In Figure 9 on page 15, it is assumed that the developer specifies an SoC subsystem by selecting the processor, bus fabric, IP blocks, and memory subsystem in CoreConsole. In this example, the user selects the following: * * * * * ARM7 processor, AMBA AHB bus fabric MAC 10/100 IP core CoreUART IP core External SSRAM and Flash memory * Due to the rapid prototyping capability of FPGAs, however, integration of hardware and software often occurs earlier in the SoC development cycle for FPGA targets than it would for ASIC targets. Therefore, hardware and software co-verification, which can be very slow, is not a critical issue except in the most complex FPGA-based SoCs. The planned availability of ARM-based SoC solutions to Actel FPGA customers necessitates that Actel provide support for the test approaches described above. In particular, there should be an emphasis on providing solutions for hardware simulation and for software simulation. A software simulation solution is already available to customers as part of the proposed ARM package. This package contains the RealView Instruction Set Simulator, which provides ARM7 instruction accurate simulation, as well as powerful features, such as integration with the RealView debugger. Support for hardware simulation is also proposed. The CoreConsole SoC configuration utility provides a means for the developer to stitch together IP blocks using a bus fabric of choice. It generates a system testbench, controlled by a script-driven, bus functional model (BFM) of the ARM7 processor. The ARM7 BFM allows the developer to model low-level bus transactions, which allow verification of connectivity of the various IP blocks As a result of constructing the CoreConsole subsystem, the memory map for the system is created. Based on this information, CoreConsole generates the following outputs, among others: * * * * * Verilog/VHDL model of SoC subsystem Verilog/VHDL models of IP cores Verilog/VHDL model of ARM7 BFM BFM test script System-level skeleton testbench The BFM acts as a pin-for-pin replacement of the ARM7TDMI-S in the SoC subsystem. It initiates bus transactions on the native ARM7 bus, which are cycleaccurate with real bus cycles that the ARM7TDMI-S would produce. It has no knowledge, however, of real ARM7 instructions. At this point, the BFM may be used to run a basic test of the SoC subsystem using the skeleton system testbench. The BFM is fully integrated into the CoreConsole user flow. In particular, if the user has an AHB-based COREMP7 subsystem, CoreConsole automatically derives the memory map of the user's subsystem. CoreConsole uses this information to generate an overall BFM test script, which includes customized "scriptlets" for each resource attached to the AHB or APB buses. 14 v2.6 COREMP7 SoC System Testbench SoC W rapper SoC Subsystem Memory Controller ARM7-AHB Bridge ARM7 BFM BFM Test Script SSRAM MAC 10/100 Flash Video Codec CoreUART BFM Log File UserDefined Tasks and Function Video Test Stub MAC Test Stub Figure 9 * SoC System-Level Testbench Example The developer may edit the SoC Verilog/VHDL to add new design blocks, such as the VideoCodec in the above diagram. The system-level testbench may also be filled out by the developer to include tasks that test any newly added functionality or additional stubs that allow more complex system testing involving the IP cores. The BFM input scripts may also be manually enhanced to allow the user to test access to register locations in newly added logic. In this way, the user can provide stimuli to the system from the inside (via the ARM7 BFM), as well as from the outside (via testbench tasks). Figure 10 shows the design flow into which the BFM fits. User Input Memory Map Definition IP Cores Selection Bus Fabric Selection Actel IP Core Attributes (SPIRIT) Core Console BFM Test Script SoC System Testbench BFM Log File Figure 10 * BFM Flow Diagram v2.6 15 COREMP7 Functionality This section describes the specific functionality of the ARM7 BFM. The BFM models the ARM7 native bus. Specifically, this models the following bus signals: * * * * * * * * * * * ADDR, WDATA, RDATA, TRANS, WRITE, CLKEN, // address bus // write data bus // read data bus // next transaction type (i, n, or s) // indicates write access // clock enable Log File Generation The BFM generates output messages to the console of the simulation tool and also generates a plain text log file. BFM Script Language The following script commands are defined for use by the BFM: memmap This command is used to associate a label, representing a system resource, with a memory map location. The other BFM script commands may perform accesses to locations within this resource by referencing this label and a register offset relative to this base address. The BFM also models the following control signals: CFGBIGEND, // big/little endian configuration CLK, nFIQ, nIRQ, SIZE, // clock // interrupt request // fast interrupt request // memory access width Syntax memmap resource_name base_address; resource_name This is a string containing the user-friendly instance name of the resource being accessed. For BFM scripts generated automatically by CoreConsole, this name corresponds to the instance name of the associated core in the generated subsystem Verilog or VHDL. CoreConsole v1.1 ARM7 Pin Compatibility The BFM model is pin-for-pin compatible with the ARM7TDMI-S. This allows the model to be dropped into the space that would be occupied by the ARM in the Verilog/VHDL system testbench. ARM7 Bus Cycle Accuracy The bus cycle timings for the ARM7 native bus signals are specified in the ARM7TDMI Technical Reference Manual. The BFM models these bus cycles exactly. Scripting In order to provide a simple and extensible mechanism for providing stimuli to the BFM, a BFM scripting language is defined (see the "BFM Script Language" section). The scripting language can initiate writes to system resources, reads from system resources (with or without checking of expected data), and can wait for events. Self-Checking The BFM gives a pass/fail indication at the end of a test run. This is based on whether any of the expected data read checks failed or not. Endianess The BFM supports both big and little-endian memory configurations. For byte and halfword transfers, it reads and writes data from/to the appropriate data lanes. Interrupt Support The BFM has the ability to wait for either of the two ARM7 interrupt lines to be triggered, before proceeding with the remainder of the test script. base_address This is the base address of the resource, in hexadecimal. write This command causes the BFM to perform a write to a specified offset, within the memory map range of a specified system resource. Syntax write width resource_name byte_offset data; width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. resource_name This is a string containing the user-friendly instance name of the resource being accessed, as defined by the user in the memory map (when input to CoreConsole). byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. data This is the data to be written. It is specified as a hexadecimal value. Example write W videoCodec 20 11223344; 16 v2.6 COREMP7 read This command causes the BFM to perform a read of a specified offset, within the memory map range of a specified system resource. Syntax poll width resource_name byte_offset data_bitmask; width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. Syntax read width resource_name byte_offset; width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. resource_name This is a string containing the user-friendly instance name of the resource being accessed. byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. resource_name This is a string containing the user-friendly instance name of the resource being accessed, as defined by the user in the memory map (when input to CoreConsole). bitmask The bitmask is ANDed with the read data and the result is then compared to the bitmask itself. If equal, then all the bits of interest are at their required value and the poll command is complete. If not equal, then the polling continues. byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. Example read W videoCodec 20; wait This command causes the BFM script to stall for a specified number of clock periods. readcheck This command causes the BFM to perform a read of a specified offset, within the memory map range of a specified system resource, and to compare the read value with the expected value provided. Syntax wait num_clock_ticks; num_clock_ticks This is the number of COREMP7 clock periods, during which the BFM stalls (doesn't initiate any bus transactions). Syntax readcheck width resource_name byte_offset data; width This takes on the enumerated values of W, H, or B, for word, halfword, or byte. waitfiq This command causes the BFM to wait until an interrupt event (high to low transition) is seen on the nFIQ pin before proceeding with the execution of the remainder of the script. resource_name This is a string containing the user-friendly instance name of the resource being accessed, as defined by the user in the memory map (when input to CoreConsole). byte_offset This is the offset from the base of the resource, in bytes. It is specified as a hexadecimal value. data This is the expected read data. It is specified as a hexadecimal value. Example readcheck W videoCodec 20 11223344; Syntax waitfiq; waitirq This command causes the BFM to wait until an interrupt event (high to low transition) is seen on the nIRQ pin before proceeding with the execution of the remainder of the script. Syntax waitirq; poll This command continuously reads a specified location until a requested value is obtained. This command allows one or more bits of the read data to be masked out. This allows, for example, poll waiting for a ready bit to be set, while ignoring the values of the other bits in the location being read. Supported Simulation Tools BFM is delivered to the user as both a Verilog and VHDL model. v2.6 17 COREMP7 Timing Shell The BFM incorporates a timing shell, which performs setup/hold checks on inputs and delays outputs by the appropriate amount from the rising clock edge. Table 5 * Resource ssram flash uart mac videocodec Memory Map Information Actel IP Core N N Y Y N Address Range 0-3fffff 400000-7fffff c00000-c0000b d00000-d00040 e00000-e000ff Example BFM Use Case This provides an example use case of the ARM7 BFM. The example SoC used in this section is the same as that shown in Figure 9 on page 15. In this system, the developer requires two Actel IP cores: the MAC 10/100 and the CoreUART. Processor Choice In this example, the user selects an ARM7 as the processor of choice in CoreConsole. The BFM in this specification only relates to ARM7. SPIRIT Attributes CoreConsole has access to a database of Actel IP cores and a list of attributes for each core. These attributes are organized according to the SPIRIT specification, in XML. For example, in the case of the CoreUART, the attributes would indicate that there are three registers, as in Table 4. Table 4 * Offset 0 1 2 CoreUART Attributes Register Uart Status Register Uart Tx data Uart Rx data Read/Write R W R Width Byte Byte Byte Bus Fabric Selection The user may select one of a number of bus fabrics in CoreConsole. For example, the user could select AMBA AHB-Lite. However, this selection is irrelevant for the ARM7 BFM, as it is concerned only with generating native ARM7 bus based transactions. Automatic BFM Scriptlet At this point, having run CoreConsole to completion, a BFM scriptlet is available. This would look something like the following: read B uart 0; write B uart 4 bb; read B uart 8; write B mac 30 11; readcheck B mac 11; Based on these attributes, CoreConsole can determine that when generating the BFM script, there are three locations corresponding to the UART that can be accessed. In this case, none of the registers are RW, so there will not be any self-checking that can be performed for the UART. Nevertheless, the bus transactions do take place and the cycles may be viewed in a waveform of the simulator. Run BFM The developer can run the BFM with the automatic script or edit the script to put in bus transactions to/from any new logic that has been added to the SoC. For example, transactions to/from the registers in the new VideoCodec block could be added. The skeleton system-level testbench, generated by CoreConsole, could also be modified, to add some external resources (e.g., models of SSRAM and Flash) and some high-level tasks. Upon running the system simulation, messages appear in the console window of the simulation tool. Memory Map The designer must feed in the memory map of the SoC to CoreConsole. During this stage, the absolute address ranges of the various system resources in the ARM7 memory map are fed in. Also, user-friendly instance names of these resources are fed in. For example, the user could feed the memory map information into CoreConsole that is given in Table 5. Based on the information in Table 5, CoreConsole generates the SoC subsystem corresponding to the Actel IP cores present. It also generates a BFM script, which accesses all the registers in the Actel IP cores. 18 v2.6 COREMP7 AC Parameters This section gives the AC timing parameters of the COREMP7 processor. Timing Diagrams Timing diagrams are shown in Figure 11, Figure 12 on page 20, Figure 13 on page 20, Figure 14 on page 21, and Figure 15 on page 21. Data Access Timing CLK TRANS[1:0] tovtrans tohtrans ADDR[31:0] tovaddr WRITE SIZE[1:0] PROT[1:0] tovctl WDATA[31:0] (write data) tovwdata CLKEN tisclken tihclken ABORT tisabort tihabort RDATA[31:0] (read data) tisrdata tihrdata Figure 11 * Data Access Timing TRANS Addr tohaddr Ctrl tohctl tohwdata Data v2.6 19 COREMP7 Coprocessor Timing The Coprocessor timing is included for completeness although it is expected that the Coprocessor interface is omitted in most deployments of the COREMP7. CLK CPA CPB tiscpstart tihcpstart CPnl tovcpni CPnMREQ CPSEQ tovcpcil CPnOPC CPnTRANS CPTBIT Figure 12 * Coprocessor Timing tohcpni tohcpcil tovcpcil tohcpcil Exception Timing CLK nFIQ nIRQ tisexc tihexc nRESET tisexc tihexc CFGBIGEND tiscfg tihcfg Figure 13 * Exception Timing 20 v2.6 COREMP7 Debug Timing CLK DBGRQ tisdbgctl tihdbgctl DBGBREAK tisdbgctl tihdbgctl DBGEXT[1:0] tisdbgctl DBGACK DBGCOMMTX DBGCOMMRX tovdbgstart DBGRNG[1:0] tovdbgstart Figure 14 * Debug Timing tihdbgctl tohdbgstart tohdbgstart Scan Timing CLK DBGTCKEN tslcken tlhocken DBGTMS DBGTDI tslcil tlhocil DBGTDO tovido Figure 15 * Scan Timing tohido v2.6 21 COREMP7 AC Timing Parameter Definitions Table 6 shows target AC parameters. All figures are expressed as percentages of the CLK period at maximum operating frequency. Note: Where 0% is shown, this indicates the hold time to clock edge plus the maximum clock skew for internal clock buffering. Table 6 * Symbol tCYC tISCLKEN tIHCLKEN tISABORT tIHABORT tISRDATA tISRST tISTRST tIHRDATA tOCPTBIT tODBG tOLOMO tOVADDR tOHADDR tOVCTL tOHCTL tOVTRANS tOHTRANS tOVWDATA tOHWDATA tISCPSTAT tIHCPSTAT tOVCPCTL tOHCPCTL tOVCPNI tOHCPNI tISEXC Notes: 1. tIHCLKEN is 0 ns for the Core Plus Debug variant in all devices. 2. tIHCLKEN is 1 ns for the Core Only variant in all devices. 3. tIHRDATA is 0 ns for Core Plus Debug variant in all devices. 4. tIHRDATA is 1 ns for Core Only variant in all devices. CLK cycle time CLKEN input setup to rising CLK CLKEN input hold from rising CLK ABORT input setup to rising CLK ABORT input hold from rising CLK RDATA input setup to rising CLK nRESET input setup to rising CLK DBGnTRST input setup to rising CLK RDATA input hold from rising CLK Rising CLK to CPTBIT valid Rising CLK to DBGnEXEC, DBGINSTRVALID valid Rising CLK to DMORE, LOCK valid Rising CLK to ADDR valid ADDR hold time from rising CLK Rising CLK to control valid Control hold time from rising CLK Rising CLK to transaction type valid Transaction type hold time from rising CLK Rising CLK to WDATA valid WDATA hold time from rising CLK CPA, CPB input setup to rising CLK CPA, CPB input hold from rising CLK Rising CLK to coprocessor control valid Coprocessor control hold time from rising CLK Rising CLK to coprocessor CPnI valid Coprocessor CPnI hold time from rising CLK nFIQ, nIRQ, input setup to rising CLK AC Timing Parameters Parameter Min 100% 60% - 40% - 10% 90% 25% - - - - - >0% - >0% - >0% - >0% 20% - - >0% - >0% 10% See notes 3, 4 90% 40% 90% 90% - 90% - 50% - 40% - - 0% 80% - 40% - - Max - - See notes 1, 2 - 0% - - 22 v2.6 COREMP7 Table 6 * Symbol tIHEXC tISCFG tIHCFG tISDBGCTL tISDBGSTAT tIHDBGSTAT tOVDBGCTL tOHDBCTL tISTCLKEN tIHTCKEN tISTCTL tIHTCTL tOVTDO tOHTDO tOVDBGSTAT tOHDBGSTAT Notes: AC Timing Parameters (Continued) Parameter nFIQ, nIRQ, nRESET hold from rising CLK CFGBIGEND setup to rising CLK CFGBIGEND hold from rising CLK DBGBREAK, DBGEXT, DBGRQ input setup to rising CLK Debug status inputs setup to rising CLK Debug status inputs hold from rising CLK Rising CLK to debug control valid Debug control hold time from rising CLK DBGTCKEN input setup to rising CLK DBGTCKEN input hold from rising CLK DBGTDI, DBGTMS input setup to rising CLK DBGTDI, DBGTMS input hold from rising CLK Rising CLK to DBGTDO valid DBGTDO hold time from rising CLK Rising CLK to debug status valid Debug status hold time Min - 10% - 10% 10% - - >0% 60%` - 35% - - >0% 40% >0% Max 0% - 0% - - 0% 40% - - 0% - 0% 20% - - - 1. tIHCLKEN is 0 ns for the Core Plus Debug variant in all devices. 2. tIHCLKEN is 1 ns for the Core Only variant in all devices. 3. tIHRDATA is 0 ns for Core Plus Debug variant in all devices. 4. tIHRDATA is 1 ns for Core Only variant in all devices. Debug The ARM Debug Architecture uses a protocol converter box to allow the debugger to talk via a Joint Test Action Group (JTAG) port directly to the core. In effect, the scan chains in the core that are required for test are re-used for debugging. The architecture uses the scan chains to insert instructions directly in to the ARM core. The instructions are executed on the core and, depending on the type of instruction that has been inserted, the core or the system state can be examined, saved, or changed. The architecture has the ability to execute instructions at a slow debug speed or to execute instructions at system speed (for example, if access to an external memory was required). The fact that the debugger is actually using the JTAG scan chains to access the core is of no importance to the user, as the front end debugger remains exactly the same. The user could still use the debugger with a monitor program running on the target system or with an instruction set simulator that runs on the debugger host. In each case the debugging environment is the same. The advantages of using the JTAG port are: * * * Hardware access required by a system for test is reused for debug. Core state and system state can be examined via the JTAG port. The target system does not have to be running in order to start debug. A monitor program for example requires that some target resources are running in order for the monitor program to run. * * * Traditional breakpoints and watchpoints are available. On-chip resources can be supplemented. For example, the ARM Debug Architecture uses an on-chip macro-cell to enhance the debugging facilities available. v2.6 23 COREMP7 * A separate UART to communicate with the monitor program is not required. The debugging of the target system requires the following: * * A PC host computer running Windows to run the debugger software An EmbeddedICE Protocol Converter, a separate box which converts the serial interface to signals compatible with the JTAG interface and a target system with a JTAG interface and an ARM Debug Architecture compliant core. DBGRQ: This core signal is a level-sensitive input that causes the CPU core to enter debug state when the current instruction has completed. DBGACK: This core signal is an output from the CPU core that goes HIGH when the core is in debug state so that external devices can determine the current state of the core. RealView ICE uses these, and other signals, through the debug interface of the processor core, for example by writing to the control register of the EmbeddedICE logic. For more details, refer to the debug interface section of the ARM datasheet or technical reference manual for your core. Once the system is connected, the debugger can start communicating with the target system via the RVI-ME (which is an EmbeddedICE Interface Converter). The debug extensions consist of several scan chains around the processor core, and some additional signals that are used to control the behavior of the core for debug purposes. The most significant of these additional signals are as follows: BREAKPT: This core signal enables external hardware to halt processor execution for debug purposes. When HIGH during an instruction fetch, the instruction is tagged as breakpointed, and the core stops if this instruction reaches execute. JTAG Debug Interface The RVI-ME ICE run control unit is supplied with a short ribbon cable. These both terminate in a 20-way 2.54 mm pitch IDC connector. You can use the cable to mate with a keyed box header on the target. The pinout is shown in Figure 16. VTref nTRST TDI TMS TCK RTCK TDO nSRST DBGRQ DBGACK 1 3 5 7 9 11 13 15 17 19 2 4 6 8 10 12 14 16 18 20 Vsupply GND GND GND GND GND GND GND GND GND Figure 16 * JTAG Interface Pinout 24 v2.6 COREMP7 The signals on the JTAG interface are shown in Table 7. Table 7 * Signal DBGACK JTAG Signals I/O - Description This pin is connected in the RealView ICE run control unit, but is not supported in the current release of the software. It is reserved for compatibility with other equipment to be used as a debug acknowledge signal from the target system. It is recommended that this signal is pulled LOW on the target. This pin is connected in the RealView ICE run control unit, but is not supported in the current release of the software. It is reserved for compatibility with other equipment to be used as a debug request signal to the target system. This signal is tied LOW. When applicable, RealView ICE uses the core's scanchain 2 to put the core in debug state. It is recommended that this signal is pulled LOW on the target. Ground Open collector output from RealView ICE to the target system reset. This is also an input to RealView ICE so that a reset initiated on the target can be reported to the debugger. This pin must be pulled HIGH on the target to avoid unintentional resets when there is no connection. Open collector output from RealView ICE to the Reset signal on the target JTAG port. This pin must be pulled HIGH on the target to avoid unintentional resets when there is no connection. Return Test Clock signal from the target JTAG port to RealView ICE. Some targets must synchronize the JTAG inputs to internal clocks. To assist in meeting this requirement, you can use a returned, and retimed, TCK to dynamically control the TCK rate. RealView ICE provides Adaptive Clock Timing that waits for TCK changes to be echoed correctly before making further changes. Targets that do not have to process TCK can simply ground this pin. Test Clock signal from RealView ICE to the target JTAG port. It is recommended that this pin is pulled LOW on the target. Test Data In signal from RealView ICE to the target JTAG port. It is recommended that this pin is pulled HIGH on the target. Test Data Out from the target JTAG port to RealView ICE. It is recommended that this pin is pulled HIGH on the target. Test Mode signal from RealView ICE to the target JTAG port. This pin must be pulled HIGH on the target so that the effect of any spurious TCKs when there is no connection is benign. This pin is not connected in the RealView ICE run control unit. It is reserved for compatibility with other equipment to be used as a power feed from the target system. This is the target reference voltage. It indicates that the target has power, and it must be at least 0.628 V. VTref is normally fed from Vdd on the target hardware and might have a series resistor (though this is not recommended). There is a 10 k pull-down resistor on VTref in RealView ICE. DBGRQ - GND nSRST - Input/ Output nTRST RTCK Output Input TCK TDI TDO TMS Vsupply VTref Output Output Input Output Input Input v2.6 25 COREMP7 The EmbeddedICE logic which implements the on-chip debug function in the COREMP7 debug architecture is described in detail in the ARM7TDMI-S (rev 4) Technical Reference Manual (ARM DDI0234A), published by ARM Limited, and is available via Internet at www.arm.com. The COREMP7 debug architecture uses a JTAG port as a method of accessing the core. The debug architecture uses EmbeddedICE logic which resides on chip with the COREMP7 core. The EmbeddedICE has its own scan chain that is used to insert watchpoints and breakpoints for the COREMP7. The EmbeddedICE logic consists of two real-time watchpoint registers, together with a control and status register. One or both of the watchpoint registers can be programmed to halt the COREMP7 core. Execution is halted when a match occurs between the values programmed into the EmbeddedICE logic and the values currently appearing on the address bus, databus, and some control signals. Any bit can be masked so that its value does not affect the comparison. Either watchpoint register can be configured as a watchpoint (i.e., on a data access) or a break point (i.e., on an instruction fetch). The watchpoints and breakpoints can be combined such that: * The conditions on both watchpoints must be satisfied before the COREMP7 is stopped. The CHAIN functionality requires two consecutive conditions to be satisfied before the core is halted. Debug Communication Channel Signals Type Input Input Input Output Input Output * An example of this would be to set the first breakpoint to trigger on an access to a peripheral and the second to trigger on the code segment that performs the task switching. Therefore the breakpoints trigger the information regarding which task has switched out that will be ready for examination. The watchpoints can be configured such that a range of addresses are enabled for the watchpoints to be active. The RANGE function allows the breakpoints to be combined such that a breakpoint is to occur if an access occurs in the bottom 256 bytes of memory but not in the bottom 32 bytes. The COREMP7 core has a Debug Communication Channel function in-built. The debug communication channel allows a program running on the target to communicate with the host debugger or another separate host without stopping the program flow or even entering the debug state. The debug communication channel is accessed as coprocessor 14 by the program running on the COREMP7 core. The debug communication channel allows the JTAG port to be used for sending and receiving data without affecting the normal program flow. The debug communication channel data and control registers are mapped in to addresses in the EmbeddedICE logic. Table 8 * Signal Name TMS TCK TDI TDO nTRST RTCK Description Test Mode Select. The TMS pin selects the next state in the TAP state machine. Test Clock. This allows shifting of the data in, on the TMS and TDI pins. It is a positive edge triggered clock with the TMS and TCK signals that define the internal state of the device. Test Data In. This is the serial data input for the shift register. Test Data Output. This is the serial data output from the shift register. Data is shifted out of the device on the negative edge of the TCK signal. Test Reset.The nTRST pin can be used to reset the test logic within the EmbeddedICE logic. Returned Test Clock. Extra signal added to the JTAG port. Required for designs based on COREMP7 processor core. Multi-ICE (development system from ARM) uses this signal to maintain synchronization with targets having slow or widely varying clock frequency. For details, refer to the Multi-ICE System Design Considerations Application Note 72 (ARM DAI 0072A). 26 v2.6 COREMP7 The EmbeddedICE logic contains 16 registers, as shown in Table 9. The COREMP7 debug architecture is described in detail in ARM7TDMI-S (rev 4) Technical Reference Manual (ARM DDI0234A), published by ARM Limited, and is available via Internet at www.arm.com. Table 9 * Name Debug Control Debug Status Debug Comms Control Register Debug Comms Data Register Watchpoint 0 Address Value Watchpoint 0 Address Mask Watchpoint 0 Data Value Watchpoint 0 Data Mask Watchpoint 0 Control Value Watchpoint 0 Control Mask Watchpoint 1 Address Value Watchpoint 1 Address Mask Watchpoint 1 Data Value Watchpoint 1 Data Mask Watchpoint 1 Control Value Watchpoint 1 Control Mask EmbeddedICE Logic Registers Width 6 5 32 32 32 32 32 32 9 8 32 32 32 32 9 8 Description Force debug state, disable interrupts Status of debug Debug communication control register Debug communication data register Holds watchpoint 0 address value Holds watchpoint 0 address mask Holds watchpoint 0 data value Holds watchpoint 0 data mask Holds watchpoint 0 control value Holds watchpoint 0 control mask Holds watchpoint 1 address value Holds watchpoint 1 address mask Holds watchpoint 1 data value Holds watchpoint 1 data mask Holds watchpoint 1 control value Holds watchpoint 1 control mask Address 00000 00001 00100 00101 01000 01001 01010 01011 01100 01101 10000 10001 10010 10011 10100 10101 v2.6 27 COREMP7 Ordering Information All variants of the COREMP7 soft IP core are included in the CoreConsole IDP. To use COREMP7, you need to download CoreConsole, which is available for free at: http://www.actel.com/custsup/updates/coreconsole/. You can also request that a CoreConsole CD (which includes COREMP7) be mailed to you. List of Changes The following table lists critical changes that were made in the current version of the document. Previous Version Changes in Current Version (v 2 .6 ) v2.5 The "ARM Supported Families" section was updated to remove ProASIC3E (M7A3PE). The "Device Utilization" section was updated. The COREMP7S variant was renamed to Core Only and the COREMP7Sd variant was renamed to Core Plus Debug. Table 1 * COREMP7 Utilization and Performance was updated to remove all devices except M7AFS600 and M7A3P1000 and to change the names of the COREMP7 variants to Core Only and Core Plus Debug. The "COREMP7 Variants" section was updated. The "Delivery and Deployment" section was updated. The "BFM Usage Flow" section was updated to clarify creation of the system memory map. v2.4 Table 1 was updated. Notes were added to Table 6. v2.3 Table 1 was updated with AFS600 information. The "Bus Functional Model" section was updated. Notes were added to Table 6. v2.2 The datasheet was updated to include Fusion devices. Table 1 was updated. The "COREMP7 Variants" section was updated. v2.1 v2.0 Table 1 was updated. The "No Coprocessor Interface" section was updated. The "Little Endian Only" section was updated. Page 1 2 2 13 14 14 2 22 2 14 22 NA 2 13 2 13 13 28 v2.6 COREMP7 Datasheet Categories In order to provide the latest information to designers, some datasheets are published before data has been fully characterized. Datasheets are designated as "Product Brief," "Advanced," and "Production." The definitions of these categories are as follows: Product Brief The product brief is a summarized version of an advanced or production datasheet containing general product information. This brief summarizes specific device and family information for unreleased products. Advanced This datasheet version contains initial estimated information based on simulation, other products, devices, or speed grades. This information can be used as estimates, but not for production. Unmarked (production) This datasheet version contains information that is considered to be final. v2.6 29 Actel and the Actel logo are registered trademarks of Actel Corporation. All other trademarks are the property of their owners. www.actel.com Actel Corporation 2061 Stierlin Court Mountain View, CA 94043-4655 USA Phone 650.318.4200 Fax 650.318.4600 Actel Europe Ltd. Dunlop House, Riverside Way Camberley, Surrey GU15 3YL United Kingdom Phone +44 (0) 1276 401 450 Fax +44 (0) 1276 401 490 Actel Japan www.jp.actel.com EXOS Ebisu Bldg. 4F 1-24-14 Ebisu Shibuya-ku Tokyo 150 Japan Phone +81.03.3445.7671 Fax +81.03.3445.7668 Actel Hong Kong www.actel.com.cn Suite 2114, Two Pacific Place 88 Queensway, Admiralty Hong Kong Phone +852 2185 6460 Fax +852 2185 6488 51700060-6/7.07 |
Price & Availability of COREMP7
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |